In a world of cross-platform connectivity and 8 MB word processors, the interface solutions of yesterday just aren’t enough. If we want to deliver the power that our customers demand, while still making our applications usable, we’re going to need some new ideas.
Back in June, I proposed five new interface design techniques for dealing with our complex world. These were:
•Constraints: to lead users through a system by restricting their choices (I wrote about this in the June 1992 Apple Direct)
•Intelligence: to take “busy work” out of the user’s way (Apple Direct, August 1992)
•Elegance: to give grace and simplicity to our designs (Apple Direct, September 1992)
•Attention to detail: to make our interface—our “user illusions”—believable (Apple Direct, October 1992)
This month, I’d like to turn to the last of the five techniques, namely transparency: to keep the interface itself out of the user’s way.
Transparency is a bit of a sticky concept in human interface. To give you an idea of this, there’s been a raging debate about whether interfaces should be transparent or translucent. Academic debates like this are amusing in psychology classes, but they don’t really give you a feel for how your software should be designed. As such, I’m just going to talk about transparency by using the trusty “restaurant analogy”…
“Hi, I’m Bob! I’ll be Your Waiter for This Evening!”
A transparent interface is like a great waiter: constantly attentive without really being noticeable. Great waiters serve your food, refill your glass, and clear your dishes without ever interrupting the flow of conversation. They let you enjoy every moment of the dinner, from their graceful presentation of the menus, to the moment they elegantly present you with the bill.
Unfortunately, great waiters are none too common. People have to go to school to learn to be great waiters, and even then it’s usually a sort of initiation for first-year culinary school students.
The people who normally serve us are terrible waiters. And the very worst waiters are found in North Hollywood restaurants when you’re trying to have a romantic tête-á-tête. They’re the waiters that shatter any sense of romance by stopping by every five minutes to ask, “How’s everything going?”. The name of every one of these waiters is Bob. And they’re really actors.
Bob is not, to put it nicely, transparent.
The ideal interface, like the ideal waiter, is one that you don’t have to think about. We would say such an interface is transparent—not because we can’t see it, but because we don’t really think about it. With such an interface, our full attention is geared toard getting our work done, instead of just working the interface.
One of the biggest barriers to transparency today is the mere fact that so much of our work with computers requires a keyboard. In the future, technologies like voice recognition and pen input will help people to worry more about the work they’re doing and less about how to convince the computer to do it. Needless to say, Apple is very interested in this.
In the meantime, your application can become more transparent by following a few simple rules.
Rule 1:
Hide Features in Plain Sight
Strangely enough, the first step toward creating a transparent interface is to make the interface visible. Don’t make your users remember secret symbols, gestures, or commands to do their work. If to add page numbers to a document users have to look on page 103 of the manual, then type the secret key they find there (Option-Shift-P), they’re not going to remember what they were writing in the first place. If you make the interface visible, users don’t have to waste time on these “command safaris.”
Rule 2:
Avoid Computerese
Don’t have your program babble on in computerese unless the users are programmers. Don’t say “Query” when you could say “Find.” Don’t say “Access” when you could say “Open,” and don’t say “SysErr Code:–34” when you could say “The disk is full.”
Rule 3:
Keep Status Messages Simple
Don’t burden the user with needless programmatic detail when giving status messages. Let the user know (in a general way) what’s happening, and how long it will take. It doesn’t help most users to know that your telecommunications program has just “Initiated CCL Script Parsing” and will soon be on its way toward achieving “Name Server Access.” Give frequent status information, but keep it simple enough to understand. If you can’t think of anything more meaningful, just say “Connecting: Step 1,” “Connecting, Step 2,” and so on.
Rule 4:
Don’t Interrupt (or if You Must, Do It Quietly)
Our friend Bob the actor-waiter loves to barge in on the middle of romantic conversation to ask, “And how’s everyone’s warm duck salad tonight?!” This is why we hate Bob.
Think about this before you use the Notification Manager to display a modal dialog box from the background. Is what you’re saying that important? Or would blinking the application menu icon do just as well?
Clinical studies show that whenever a background process (like a waiter) interrupts a foreground task (like hand-holding), the result is an increase in the stress level of the person performing the foreground task. This response is in direct proportion to the level of intrusiveness. So if Bob is going to loudly interrupt a romantic moment, he’d better be telling us our car is being stolen. In that case, we can channel that stress against the thief.
Otherwise, we’ll direct it at Bob.
The Extra HI Design Mile
It’s sobering to remember that both the original Macintosh System Software and a word processor fit on a single 400K disk, worked in 128K of RAM, and could be learned in minutes. What a long way we’ve come from that in just eight years.
If we want to keep the same ease-of-use in today’s complex world, we’re going to need some new ideas. I’ve pontificated on some of my own, but now it’s time to listen to you. Don’t forget, this is your column, too. Sure, we interface folks may pound the soapbox for an issue or five, but I’m also here to help with your questions and concerns. So send me an AppleLink message at THE.DOKTOR, and I’ll do my best to answer you.
Till next time,
—Doc
Pete Bickford runs the Human Interface Lab at Apple’s IS&T (Information Systems and Technology) organization.
Taken from Apple Direct, November/December 1992 @ Apple Computer
$ ◊# ˇ ˇˇˇˇ # ◊
d , Times
$ . ° d ONLN d ) M˙ +6c Transparency, or “Death Comes ° d ONLN d M q/ *$to Bob the Waiter”
° d ONLN d 1 Å è v *$by Pete Bickford
° d ONLN d C ß ≥’ *$^In a world of cross-platform connectivity and 8 MB word processors, the interface solutions of ° d ONLN d ¢ π ≈Ë *dyesterday just aren’t enough. If we want to deliver the power that our customers demand, while still ° d ONLN d À ◊] *Cmaking our applications usable, we’re going to need some new ideas. ° d ONLN dK › ! ÈÓ + aBack in June, I proposed five new interface design techniques for dealing with our complex world. ° d ONLN d≠ Ô ˚ P ( 6 These were: ° d ONLN dπ !
˛ + i•Constraints: to lead users through a system by restricting their choices (I wrote about this in the June ° d ONLN d# 3 (; 61992 ° d ONLN d( 3 o ) Apple Direct ° d ONLN d4 o s )<) ° d ONLN d6% !13 (M ?:•Intelligence: to take “busy work” out of the user’s way ( ° d ONLN dp%31r (MQ
Apple Direct, ° d ONLN d}%r1∂ )?
August 1992) ° d ONLN dã7 !C" (_ ?8•Elegance: to give grace and simplicity to our designs ( ° d ONLN d√7"Ca (_@
Apple Direct, ° d ONLN d–7aCµ )? September 1992) ° d ONLN d·I !Uê (q ?M•Attention to detail: to make our interface—our “user illusions”—believable ( ° d ONLN d.IêU“ (qÆApple Direct, ° d ONLN d<I“U¯ )BOctober ° d ONLN dD[ g 4 (É 61992) ° d ONLN dJm !y◊ + aThis month, I’d like to turn to the last of the five techniques, namely transparency: to keep the ° d ONLN d¨ ã ƒ (ß 6'interface itself out of the user’s way. ° d ONLN d’ë !ù˙ + gTransparency is a bit of a sticky concept in human interface. To give you an idea of this, there’s been ° d ONLN d=£ ØÌ (À 6da raging debate about whether interfaces should be transparent or translucent. Academic debates like ° d ONLN d¢µ ¡Á *cthis are amusing in psychology classes, but they don’t really give you a feel for how your software ° d ONLN d« ”¯ *fshould be designed. As such, I’m just going to talk about transparency by using the trusty “restaurant ° d ONLN dmŸ  Q * analogy”… ° d ONLN dxÛ ˇ ' *“H
° d ONLN dzÙ '˛ + )I
° d ONLN d{Û +ˇ 9 ), I’
° d ONLN dÙ 9˛ E )M
° d ONLN dÅÛ Eˇ M ) B
° d ONLN dÇÙ M˛ \ )OB
° d ONLN dÑÛ \ˇ k )! I’
° d ONLN dàÙ k˛ ç )LL BE
° d ONLN déÛ çˇ ï )"Y
° d ONLN dèÙ ï˛ Æ )OUR
° d ONLN dìÛ Æˇ ∫ )W
° d ONLN dîÙ ∫˛ Ù )
AITER FOR
° d ONLN dûÛ Ùˇ ¸ ):T
° d ONLN düÙ ¸˛ )HIS
° d ONLN d£Ûˇ )E
° d ONLN d§Ù˛@ )VENING
° d ONLN d™Û@ˇJ )(!” ° d ONLN dÆ Û (1 6kA transparent interface is like a great waiter: constantly attentive without really being noticeable. Great ° d ONLN d 'Í *gwaiters serve your food, refill your glass, and clear your dishes without ever interrupting the flow of ° d ONLN dÇ- 9Ï *dconversation. They let you enjoy every moment of the dinner, from their graceful presentation of the ° d ONLN dÁ? K: *>menus, to the moment they elegantly present you with the bill. ° d ONLN d'Q !]Ì + bUnfortunately, great waiters are none too common. People have to go to school to learn to be great ° d ONLN däc o√ (ã 6awaiters, and even then it’s usually a sort of initiation for first-year culinary school students. ° d ONLN dÌu !Å˘ + dThe people who normally serve us are terrible waiters. And the very worst waiters are found in North ° d ONLN dRá ìfi (Ø 6aHollywood restaurants when you’re trying to have a romantic tête-á-tête. They’re the waiters that ˇŒ ◊# ˇ ˇˇˇˇ # ◊
d , Times
. ° d ONLN d ) 5Ò +6Qashatter any sense of romance by stopping by every five minutes to ask, “How’s everything going?”. ° d ONLN d b ; Go *IThe name of every one of these waiters is Bob. And they’re really actors. ° d ONLN d ¨ M ! Y ÷ + *Bob is not, to put it nicely, transparent. ° d ONLN d ◊ _ ! k¸ *hThe ideal interface, like the ideal waiter, is one that you don’t have to think about. We would say such ° d ONLN d@ q }˛ ( ô 6ian interface is transparent—not because we can’t see it, but because we don’t really think about it. With ° d ONLN d™ É èÔ *hsuch an interface, our full attention is geared toard getting our work done, instead of just working the ° d ONLN d ï ° C *
interface. ° d ONLN d ß ! ≥‚ + `One of the biggest barriers to transparency today is the mere fact that so much of our work with ° d ONLN d π ≈˛ ( · 6icomputers requires a keyboard. In the future, technologies like voice recognition and pen input will help ° d ONLN dÈ À ◊˘ *cpeople to worry more about the work they’re doing and less about how to convince the computer to do ° d ONLN dM › È *6it. Needless to say, Apple is very interested in this. ° d ONLN dÑ Ô ! ˚„ + ^In the meantime, your application can become more transparent by following a few simple rules. ° d ONLN d„ ! (1 6R
° d ONLN d‰
! 9 ) ULE
° d ONLN dË 9 C )1: ° d ONLN dÏ ' ! (C 6H
° d ONLN dÌ !& 6 ) IDE
° d ONLN dÒ 6' = )F
° d ONLN dÚ =& | ) EATURES IN
° d ONLN d˝ |' É )?P
° d ONLN d˛ É& † )LAIN
° d ONLN d †' ß ) S
° d ONLN d ß& ¿ )IGHT
° d ONLN d 1 =Ú (Y 6jStrangely enough, the first step toward creating a transparent interface is to make the interface visible. ° d ONLN dtC OÓ *`Don’t make your users remember secret symbols, gestures, or commands to do their work. If to add ° d ONLN d’U aÍ *apage numbers to a document users have to look on page 103 of the manual, then type the secret key ° d ONLN d7g s„ *cthey find there (Option-Shift-P), they’re not going to remember what they were writing in the first ° d ONLN dõy ÖÔ *dplace. If you make the interface visible, users don’t have to waste time on these “command safaris.” ° d ONLN d ì ü ! *R
° d ONLN dî !û 9 ) ULE
° d ONLN dì 9ü C )2: ° d ONLN d • ± ! (Õ 6A
° d ONLN d
¶ !∞ > ) VOID
° d ONLN d• >± G ) C
° d ONLN d¶ G∞ ã )
OMPUTERESE
° d ONLN dª «„ („ 6\Don’t have your program babble on in computerese unless the users are programmers. Don’t say ° d ONLN dxÕ Ÿ˚ *Z“Query” when you could say “Find.” Don’t say “Access” when you could say “Open,” and don’t ° d ONLN d”fl ÎK *<say “SysErr Code:–34” when you could say “The disk is full.” ° d ONLN d˘ ! *R
° d ONLN d˙ ! 9 ) ULE
° d ONLN d˘ 9 C )3: ° d ONLN d ! (3 6K
° d ONLN d ! 8 ) EEP
° d ONLN d 8 ? )S
° d ONLN d ? ` )TATUS
° d ONLN d% ` k )!M
° d ONLN d& k õ ) ESSAGES
° d ONLN d. õ ¢ )0S
° d ONLN d/ ¢ √ )IMPLE
° d ONLN d5! -Í (I 6aDon’t burden the user with needless programmatic detail when giving status messages. Let the user ° d ONLN dó3 ? *bknow (in a general way) what’s happening, and how long it will take. It doesn’t help most users to ° d ONLN d˙E Q˙ *bknow that your telecommunications program has just “Initiated CCL Script Parsing” and will soon be ° d ONLN d]W c *`on its way toward achieving “Name Server Access.” Give frequent status information, but keep it ° d ONLN dæi uı *csimple enough to understand. If you can’t think of anything more meaningful, just say “Connecting: ° d ONLN d "{ á ‚ *)Step 1,” “Connecting, Step 2,” and so on. ˇ ◊# ˇ ˇˇˇˇ # ◊
d , Times
. ° d ONLN d ) 5 ! +6QR
° d ONLN d * ! 4 9 ) ULE
° d ONLN d ) 9 5 C )4: ° d ONLN d ; G ! ( c 6D
° d ONLN d
< ! F 0 ) ON
° d ONLN d ; 0 G 4 )’
° d ONLN d
< 4 F < )T
° d ONLN d ; < G @ )I
° d ONLN d < @ F v ) NTERRUPT
° d ONLN d ; v G { )6(
° d ONLN d < { F ö )OR IF
° d ONLN d ; ö G ¢ ) Y
° d ONLN d ! < ¢ F ¥ )OU
° d ONLN d $ ; ¥ G ø )M
° d ONLN d % < ø F – ) UST
° d ONLN d ( ; – G fl ), D
° d ONLN d + < fl F Í )O
° d ONLN d - ; Í G Ó ) I
° d ONLN d . < Ó F ˆ )T
° d ONLN d 0 ; ˆ G ˇ )Q
° d ONLN d 1 < ˇ F$ ) UIETLY
° d ONLN d 7 ;$ G) )%) ° d ONLN d 9 Q ]ˆ ( y 6eOur friend Bob the actor-waiter loves to barge in on the middle of romantic conversation to ask, “And ° d ONLN d ü c on *Dhow’s everyone’s warm duck salad tonight?!” This is why we hate Bob. ° d ONLN d  u ! ÅÈ + _Think about this before you use the Notification Manager to display a modal dialog box from the ° d ONLN dE á ì˛ ( Ø 6ebackground. Is what you’re saying that important? Or would blinking the application menu icon do just ° d ONLN d´ ô • = *as well? ° d ONLN dµ ´ ! ∑˚ + eClinical studies show that whenever a background process (like a waiter) interrupts a foreground task ° d ONLN d Ω …˙ (  6j(like hand-holding), the result is an increase in the stress level of the person performing the foreground ° d ONLN dÜ œ €Î *htask. This response is in direct proportion to the level of intrusiveness. So if Bob is going to loudly ° d ONLN dÔ · Ì‹ *dinterrupt a romantic moment, he’d better be telling us our car is being stolen. In that case, we can ° d ONLN dT Û ˇ æ *&channel that stress against the thief. ° d ONLN d| ! π + "Otherwise, we’ll direct it at Bob. ° d ONLN dü + (G 6T
° d ONLN d∏5 AÙ (] 6cIt’s sobering to remember that both the original Macintosh System Software and a word processor fit ° d ONLN d G SÌ *^on a single 400K disk, worked in 128K of RAM, and could be learned in minutes. What a long way ° d ONLN d{Y e ◊ *)we’ve come from that in just eight years. ° d ONLN d•k !wÌ + ^If we want to keep the same ease-of-use in today’s complex world, we’re going to need some new ° d ONLN d} Ⲡ(• 6jideas. I’ve pontificated on some of my own, but now it’s time to listen to you. Don’t forget, this is your ° d ONLN doè õÙ *fcolumn, too. Sure, we interface folks may pound the soapbox for an issue or five, but I’m also here to ° d ONLN d÷° ≠˚ *^help with your questions and concerns. So send me an AppleLink message at THE.DOKTOR, and I’ll ° d ONLN d5≥ ø î *do my best to answer you. ° d ONLN dO≈ !— a + Till next time, ° d ONLN d_◊ !„ D *—Doc
